Listening to the Poke..

‍ Listening to the Poke

Processing acceleration data from explicit simulation — and the difference between a good listener and a great one.

The essay edition. This is the same material as the audiobook of the same name, set for reading. A deeper technical companion — with the measured verification data, the filter mathematics and a printable bench card — is published separately.

I'm Joseph McFadden. I've spent more than forty years as an engineer, an educator, and an investigator of failures. Over those years I've broken a great many things — some on purpose, on fixtures I designed myself, and some the ordinary way, which is to say by accident, followed by a quiet moment of reflection about what the system was trying to tell me before it broke.

Why this subject, and not some other

Explicit dynamics is Newton's second law, marched forward in very small steps. Force equals mass times acceleration. That is the entire engine. You poke a mass with a net force, and the thing that mass does — the only thing it does — is accelerate.

So acceleration is not one output among many. It is the quantity the solver is actually computing, step after step after step. Velocity, displacement, deformation: every one of them is downstream of it.

And yet. Ask a room of experienced analysts what the acceleration was, and watch what happens. You will hear that it is too noisy to report. You will hear that it could be off by who knows how much. And then, almost always, you will hear the reassurance that the deformation looks right, the failure modes look right, the behavior we actually care about is fine.

That reassurance is usually true. But sit with the strangeness of it for a moment. The one quantity the whole method is built upon is the one quantity we have quietly agreed not to quote.

I was not willing to leave it there. Not out of stubbornness, but because the products I was responsible for got dropped for a living, and the question on the table was always fragility. What did that component actually feel? That is an acceleration question, and there is no way around it.

So I went reading — everything I could find. And one paper went straight to the bone: Diehl, Carroll and Nagaraj, 1999, out of Motorola.

Here is the part I still enjoy. When I first read that paper, its authors were strangers to me. Some years later Symbol Technologies, the company I worked within, was acquired by Motorola — and the strangers whose paper had rescued me turned out to be colleagues. This field is smaller than it looks.

From that paper, and from a great many other sources, I built an approach. First for myself, then for the simulation team I formed at Symbol, and later carried into Zebra Technologies. Not a trick, and not a setting: a discipline. An order of operations you could hand to a young engineer and know that the number arriving at the far end of it could be defended in a design review.

I no longer run the day-to-day work of that team. These days I am the technical lead, which is a polite way of saying the mentor. What I have been doing with that role is partnering with a number of AI tools to turn the approach into something teachable — software with a full learning centre built into it, patterned after the holistic method described here. One of those tools is the one I will name throughout: MDSP, the Mechanical Digital Signal Processor. I developed it on my own, with my own resources, and I give it away: on my blog, and to my students at Fairfield University in Connecticut, where I also teach as an adjunct. So when you read that our software does it this way, you are welcome to go and check.

What follows is about listening. Specifically, about what happens between the moment a simulation answers you and the moment you actually understand what it said. There is a craft in that gap, and there is a wisdom one level above the craft. Stay to the end, because the last part is the part I most want you to carry home.

Part One. The poke, and the edited answer

We poke systems to understand them. A child pushes the new toy. A mechanic taps the casting. And we drop a product onto simulated concrete and ask one node — at the centre of mass of a block that stands in for an engine — to write down everything it felt.

Here is the idea underneath everything that follows. The answer is never the original poke. The system edits it. Every surface, every bond, every element in the mesh reflects it, scatters it, rewrites it according to the system's structure, its state, and its history. What reaches you is the edited answer. And learning to read the edit is most of what analysis actually is.

The edit arrives garbled in three distinct ways, and you should be able to name all three, because each one gets a different response.

The first: the solver's breathing

An explicit solver does not march through time at a steady pace. It advances only as far as the smallest, stiffest element will safely allow in one step. That limit is set by the time it takes a stress wave to cross the tiniest element — the Courant–Friedrichs–Lewy condition, usually called the CFL limit. When an element deforms, or contact engages, or a sharp corner stiffens, the allowable step shrinks. So the answer comes to you with an irregular heartbeat.

That is not corruption. That is the solver working hardest exactly where the most is happening.

The second: the mesh's own voice

An elastic impact model is not a continuous solid. It is a box full of tiny springs and masses, a discrete approximation of the real continuum. When you strike it, every one of those springs rings at its own natural frequency. That ringing is enormous — often larger than the physics you care about — and it lives at ferocious frequencies, hundreds of kilohertz, set not by your product but by the size and stiffness of your elements. Your fifty-g impact arrives wearing a coat of fuzz a thousand g thick.

The third: your own sampling

The third is the only one that is ours. Suppose you asked the solver to write output only every so often — some comfortable interval — because the full file seemed absurdly large. All that ferocious ringing does not disappear when you sample it coarsely. It folds. Every frequency too fast for your sampling rate reflects back down into the band you trust, wearing a disguise.

A hundred-kilohertz ring, lazily sampled, can masquerade as a smooth, gentle, one-kilohertz wave, indistinguishable from physics. Think of the wagon-wheel effect in an old movie: the spokes appear to rotate slowly, or even backward, because the camera sampled too slowly to catch the true motion. The wheel is not lying. The camera is simply too slow to tell the truth.

The rule that governs this is old, and it is unforgiving. To capture a signal honestly you must sample it more than twice as fast as the fastest thing living inside it. Half your sampling rate is the ceiling, and that ceiling has a name: the Nyquist frequency. Everything above it does not get lost. It gets folded back underneath and handed to you as a lower frequency that was never there.

And now the fine print, which is where engineers get hurt. Twice is the mathematical minimum. It is not an engineering target. Sample at twice and you may recover the frequency while completely missing the height of the peak. If you want a peak to still look like a peak, ten times is the honest number. This is precisely what Ted Diehl and his colleagues demonstrated in that 1999 paper — and a quarter century later it is still the number one error in this field.

That is aliasing, and it deserves a moment of respect, because it is unlike every other corruption in this story. Noise announces itself. Drift can be spotted. Clipping leaves flat-topped fingerprints. Aliasing leaves no evidence. Once it is in the record, no filter, no algorithm, no expert can remove it, because the record itself has become a plausible lie. The only defence is to never let it in. Capture every increment the solver computed, however large the file. Storage is cheap. A confident wrong answer about a component going into a million devices is not.

Part Two. The good listener: filtering with intent

A good listener, faced with a garbled message, does not panic and does not guess. They work in order. And the order is the craft.

First: restore the clock

The raw output arrives with uneven time steps, and most analysis tools assume equal spacing. So you regularize onto a steady time base at the solver's finest step, so that nothing which happened in those small, frantic moments gets averaged away. And interpolate gently: a straight line between points, nothing fancier — because fancy interpolation invents little overshoots near sharp events, and inventing is the one thing a listener must never do.

Second: guard filter, then decimate

Second — and only second — step back from the detail. The record is enormous, and most of its bandwidth is mesh-song, not physics. You are allowed to reduce it. But hear this clearly: decimation is not deletion. Before you keep every tenth point, you must first quiet everything the smaller record cannot faithfully carry — a low-pass filter clamped down before the downsampling, so the high frequencies die honestly instead of folding down as aliases. That pairing — filter, then thin — is what the word decimation properly means. Doing it in the other order is how smooth fiction gets manufactured.

Third: the analysis filter

Third, and only now, the analysis filter. And notice I said analysis filter. There are two filters in this story, and they are not the same filter. The first rides inside decimation — a guard at the door, whose only job is to make sure nothing too fast gets thinned into a lie. The second separates the impact you care about from the residue of ringing. Guard filter before the thinning; analysis filter after. Say it that way and the order never confuses you again.

Why after? A practical reason with teeth. A filter tuned to a few kilohertz, built against a ten-megahertz record, is numerically treacherous: its mathematics crowd into a corner and quietly fall apart. The same filter, built against the reduced record, is exact. Thin first, analyse second. Not preference — arithmetic.

Filter forward, then backward: zero-phase

Here is the trouble with an ordinary filter. A filter can only work from what it has already seen. It watches the past and makes its best judgment about the present, which means it is always running a little behind. Push a low-pass filter through your drop record in the normal way, front to back, and everything in it comes out late. The peak moves.

And it is worse than a simple shift, because a filter does not delay every frequency by the same amount. The slow content comes through nearly on time; the content up near the cutoff arrives noticeably late. So the pulse does not merely move. It smears. It leans. The very shape you set out to measure quietly changes on the way through.

Does a fraction of a millisecond really matter? Ask what you are about to do with the record. If you are comparing two channels to see whether the bracket amplified what the housing felt, the entire answer resides in the timing between them. If you are correlating a drop test against a simulation, you are lining up two peaks. If you are integrating to velocity change, you are trusting the shape. A filter that moves the peak quietly corrupts every one of those.

So here is the remedy, and it is a lovely piece of engineering. Run the filter forward through the record, first sample to last. Then take that result and run the very same filter backward through it, last sample to first. Going forward, the filter dragged everything late. Going backward, it drags everything late again — but late in a reversed record is early in the real one. Two errors, equal and opposite. They cancel, at every frequency, exactly. The record comes out smooth, and every peak sits precisely where the physics put it. That is zero-phase filtering.

You do pay for it, and a good listener knows the price. The filter ran twice, so it bit twice as hard: your cutoff is now sharper than the number you asked for. The standards know this — SAE J211 writes its coefficients on the assumption that you will make both passes, so if you follow the standard you are fine. The trap is taking a filter you designed yourself for a single pass, running it twice, and then reporting the cutoff you typed in, which is no longer the cutoff you have.

Understand too that this filter is not causal. It uses the future to compute the present. That is perfectly legal on a record sitting in a file and completely impossible on a controller running live. And pad the ends: both edges get disturbed by the filter's startup, and now the disturbance arrives from both directions.

Zero-phase is not a step — it is how you filter

Let me be plain about where this lives in the sequence, because it is easy to mishear. Zero-phase is not a fourth step, performed once, somewhere after the filtering. It is the manner in which a filter is applied — any filter.

In MDSP, every filter in this story makes both passes automatically: the guard filter inside decimation, the analysis filter that follows, the crash-standard filter classes. Forward and backward, every time, without being asked.

But if you are listening through some other tool, do not assume. Find out how it applies a filter before you trust what comes out. A single-pass filter moves your peaks. A double-pass filter bites twice. Either one is workable, so long as you know which one you have — and say so when you report.

Choosing the cutoff: the derivative ladder

Choose the cutoff from a question, not a habit — because the metrics do not all suffer alike, and there is one simple rule sitting underneath that. Integrate, and you divide by frequency. Differentiate, and you multiply by it. And mesh-song is nothing but frequency.

Velocity change is an integral, so the ringing gets divided away on the road to ΔV, and ΔV barely notices it at all. The shock response spectrum is itself a kind of mechanical listener — it asks how a family of single-degree-of-freedom oscillators would respond, and it naturally shrugs off frequencies far above its band. But peak acceleration is neither one. It reads the record raw, and it takes the ringing at full strength. That fifty-g impact, in its thousand-g coat of fuzz, reports the coat — not the impact. Which is why a peak g quoted without its filter class is not a measurement.

And jerk — the rate of change of acceleration — is worse still. Jerk is a derivative, so it multiplies by frequency and amplifies precisely the band the ringing resides in. Quote jerk from an unfiltered explicit record and you are not quoting your product. You are quoting your mesh.

Last: never destroy the original

One more habit marks the good listener: they never destroy the original. Every cleaned, reduced, filtered version stands beside the raw record, not in place of it, with a note attached saying exactly what was done and why. The message, and the listening notes, kept together. Forever.

Part Three. The great listener: when the noise is also a message

A good listener sees the message and is not bothered by the noise. But a great listener does not merely filter. A great listener turns to the noise itself and asks: why are you here? What are you trying to tell me?

Because in a deterministic simulation almost nothing is truly random. Every so-called artefact has a cause. And the cause is information.

The ringing was a review of your model, written by the model

That coat of element ringing you filtered away — before you discarded it, did you ask what it said? Its very persistence says your model is elastically dominated: the energy of the impact has nowhere to die. And if the real product is damped as lightly as the model, the real product may ring too. And ring. And ring. Ringing is fatigue's favourite music.

Its frequency is a mesh diagnostic, delivered free of charge. It tells you the size and stiffness of your elements, and whether your mesh can even carry the frequencies your fragility question needs. The noise was a review of your own model, written by the model.

When the classifier disagrees with you, write it down

Take a day on our own bench. Our classifier looked at an explicit record and declared it random vibration. A mistake? Statistically, no. The sustained ringing genuinely dominated the record's energy, and the statistics reported that faithfully while missing the transient underneath. The great-listener response was not to silence the classifier. It was to let the human's knowledge outrank it — and write the disagreement down. Because that disagreement is itself a measurement. It tells you, in one line, how thoroughly the mesh-song covers the physics in this particular model.

A clock quantized into dust

Or the strangest one. Deep in a time column, we found the solver's steps apparently jumping between a few discrete values. It looked like adaptive stepping. It wasn't. It was the arithmetic of the computer itself: timestamps so large that the machine's number format could no longer tell fine moments apart, quantizing the clock into dust. What looked like solver behaviour was a message about provenance — about where the data had been and how it had been stored, whether in single or double precision, what units were chosen, how far the simulation had already travelled. Filter that blindly and you learn nothing. Interrogate it, and you learn something true about your data's whole journey.

Clipping: the most candid confession in measurement

Flat tops, at identical levels. The instrument telling you, plainly: I ran out of range. The samples you most wanted were never written down. No cleaning answers a confession. Only re-testing does. The great listener hears that, thanks the instrument for its honesty, and goes back for a better recording.

The discipline, in one line

Filter the noise out of the record — but never out of your notebook. Remove it from the analysis. Keep it in the inquiry. Ask every artefact for its cause before you show it the door. The message tells you about your product. The noise tells you about your model, your instruments, your data's history — the whole apparatus of listening. And only an engineer who understands the apparatus is entitled to trust the message.

Closing

We poke because that is how systems reveal their nature. The system answers — always honestly, never clearly. Between its answer and your understanding stands the craft. Restore the clock. Quiet what you cannot carry. Reduce with protection. Filter with a question in mind. Shift nothing in time. Keep the original. Write down everything you did.

And then go one step further than the craft requires. Pick up the noise you removed. Turn it over in your hands. And ask it why it came.

A good listener hears what the system said. A great listener also hears how it said it. And in that how resides the next design, the better mesh, the wiser test, and every question you didn't yet know to ask.

A note of thanks

I consider Tom Irvine one of the great educators in all things vibration, and maybe in more than that. I have never met Tom. But I have read his documents and worked through his open-source code, and that work inspired me to build on what he built — not to replace it, but to augment it. If you are a curious person, and I suspect you are or you would not still be reading, go and find him at vibrationdata.com.

I'm Joe McFadden. Thank you for reading — and for listening well.

Joseph P. McFadden Sr. — McFaddenCAE.com. Methodology after Diehl, T., Carroll, D. and Nagaraj, B., “Applications of DSP to Explicit Dynamic FEA Simulations of Elastically-Dominated Impact Problems,” Abaqus Users’ Conference, Chester, England, 1999; and Shock and Vibration 7(3), 2000, pp. 167–177. CFC filter definition per SAE J211-1 and ISO 6487. Shock response spectrum algorithms after Tom Irvine, vibrationdata.com. Developed with Claude (Anthropic), in collaboration with Grok, ChatGPT, Gemini, Perplexity and ElevenLabs.